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To  the  Reader 

Overview 

This  package  contains  a  copy  of  the  software  acquisition  process  maturity  questionnaire.  This 
questionnaire  is  intended  for  those  interested  in  performing  and  learning  about  software  acqui¬ 
sition  process  appraisals.  This  questionnaire  is  not  an  appraisal  method  itself;  rather,  it  is  a  tool 
that  may  be  used  in  different  appraisal  methods. 

Product  Description 

This  version  of  the  questionnaire  is  based  on  the  Software  Acquisition  Capability  Maturity 
ModeP"^  (SA-CMM)'.  It  has  been  designed  for  use  in  the  CMM^'^-based  appraisal  for  internal 
process  improvement  (CBA IPI)^.  This  questionnaire  focuses  solely  on  process  issues,  specif¬ 
ically  those  derived  from  the  SA-CMM.  The  questionnaire  is  organized  by  SA-CMM  key  pro¬ 
cess  areas  (KPAs)  and  covers  12  KPAs  of  the  SA-CMM  from  levels  two  and  three.  Because 
we  have  limited  the  number  of  questions,  the  questionnaire  can  usually  be  completed  in  one 
hour. 

The  questionnaire  includes  a  glossary  of  terms  and  KPA  descriptions  to  assist  respondents  who 
may  be  unfamiliar  with  CMM  terminology  .  Ample  space  is  provided  beneath  each  question  to 
allow  respondents  to  provide  additional  information  regarding  their  answers.  This  space  can  be 
used  to  provide  further  explanation  of  answers  or  to  provide  references  to  supporting  documen¬ 
tation. 

Intended  Use  of  the  Software  Process  Maturity  Questionnaire 

In  a  CBA  IPI,  the  questionnaire  helps  appraisers  to  identify  issues  to  be  explored  further  during 
the  on-site  period.  How  to  use  of  the  maturity  questionnaire  within  the  appraisal  method  is  ad¬ 
dressed  in  the  appraisal  method  documentation.  We  strongly  recommend  that  organizations 
wishing  to  use  this  questionnaire  contact  the  SEI  for  information  about  the  CMM-based  ap¬ 
praisal  method  used  for  the  SA-CMM.  This  appraisal  method  includes  specific  guidance  about 
how  to  rate  software  acquisition  processes  against  the  SA-CMM  in  a  reliable  and  repeatable 
manner.  To  contact  the  SEI,  call  the  Customer  Relations  Office  at  412-268-5800  or  send  an 
email  to  customer-relations@sei.cmu.edu. 

Reporting  Appraisal  Results  to  the  SEI 

The  SEI  encourages  organizations  that  perform  acquisition  process  appraisals  to  report  their  re¬ 
sults  to  the  SEI.  Only  through  the  willingness  of  the  software  acquisition  community  to  report 
data  and  results  can  the  SEI  provide  community  maturity  profiles,  reports  on  the  state  of  the 
practice,  and  other  analytical  services.  We  hope  that  as  a  user  of  the  questionnaire  you  will  con¬ 
tact  us.  Nondisclosure  agreements  are  available  to  provide  additional  assurance  that  the  data 
you  provide  will  be  kept  confidential.  Contact  the  Acquisition  Risk  Management  Initiative  at 
(412)  268-6936  for  details  about  reporting  results  to  the  SEI. 


’  Capability  Maturity  Model  is  a  service  mark  of  Carnegie  Mellon  University. 
CMM  is  a  service  mark  of  Carnegie  Mellon  University. 
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We  would  also  like  your  comments  on  the  questionnaire.  Please  submit  your  comments  using 
the  change  request  form  included  in  this  package. 

Contents  of  the  Package 

This  package  contains  an  instruction  placard,  a  copy  of  the  software  acquisition  process  matu¬ 
rity  questionnaire,  a  glossary  of  organizational  terms  used  in  the  questionnaire,  and  a  change 
request  form. 

Instructions  for  administering  the  questionnaire  are  included  in  the  kits  for  conducting  apprais¬ 
als.  They  are  not  included  in  this  package. 

Other  Related  SEI  Products 

The  following  SEI  products  are  related  to  the  Software  Acquisition  Process  Maturity  Question¬ 
naire.  You  can  obtain  information  on  these  products  through  the  Customer  Relations  Office  by 
phone  at  412-268-5800  or  by  e-mail  at  customer-relations@sei.cmu.edu. 


•  ’  The  maturity  model  for  software  acquisition,  entitled  the  Software  Acquisition  Capability  Maturity 

Model  (SA-CMM),  version  1.01  [Ferguson  96] 

•  The  appraisal  method  used  to  determine  software  acquisition  maturity,  entitled  the  CMM-Based 
Appraisal  for  Internal  Process  Improvement  ( CBA IPI):  Method  Description  [Dunaway  96] 

•  The  course  that  covers  software  acquisition  process  maturity  entitled  Introduction  to  the  Software 
Acquisition  Capability  Maturity  Model.  For  more  information  about  this  course,  call  SEI  Customer 
Relations  or  visit  the  SEI  Web  site  at  http://www.sei.cmu.edu/ 
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Instruction  Placard  -  Software  Acquisition  Maturity  Questionnaire 

Filling  in  Your  Answers 


will  be  using  optical  scanning  technology  to  tabulate  your  answers,  so  please  print 
or  write  neatly  throughout  the  questionnaire. 


•  Feel  free  to  use  the  margins  if  you  need  more  space  for  your  written  answers  or 
other  comments,  but  please  don’t  write  over  the  check  boxes  or  crosshair  (+) 
symbols. 

•  Please  keep  your  marks  within  the  check  boxes.  Any  mark  will  do.  B1  1^  S] 


Use  a  pen  with  dark  blue  or  black  ink. 


Definitions  of  Terms 


The  model  on  which  this  Maturity  Questionnaire  is  based  uses  a  number  of  terms 
which  may  be  used  differently  in  your  organization.  These  terms  are  defined  at  the 
beginning  of  each  questionnaire  section. 


Respondent  Identification 

(Please  specify) 
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Instruction  Placard  -  Software  Acquisition  Maturity  Questionnaire 

(continued) 


Instructions 


1.  To  the  right  of  each  question  there  are  boxes  for  the  four  possible 
responses:  Yes,  No,  Does  Not  Apply,  and  Don’t  Know. 

Check  Yes  when: 

The  practice  is  well  established  and  consistently  performed. 

The  practice  should  be  performed  nearly  always  in  order  to  be 
considered  well-established  and  consistently  performed  as  a 
standard  operating  procedure. 


Check  No  when: 

The  practice  is  not  well  established  or  is  inconsistently 
performed. 

The  practice  may  be  performed  sometimes,  but  it  is  omitted 
under  difficult  circumstances. 

Check  Does  Not  Apply  when: 

You  have  the  required  knowledge  about  the  project  or 
organization  and  the  question  asked,  but  you  feel  the  question 
does  not  apply  to  the  project. 

For  example,  the  entire  section  on  "Transition  to  Support”  may 
not  apply  to  the  project  if  you  are  acquiring  services  rather  than 
products. 

Check  Don’t  Know  when: 

You  are  uncertain  about  how  to  answer  the  question. 


2.  Use  the  Comments  spaces  for  any  elaborations  or  qualifications  about 
your  answers  to  the  questions. 


Check  one  of  the  boxes  for  each  question, 
questions. 


Please  answer  all  of  th^ 
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Software  Acquisition  Maturity  Questionnaire 

Software  Acquisition  Capability  Maturity  Model,  version  1.01 
February  1997 


This  document  contains  questions  about  the  implementation  of  important  software  acquisition 
practices  in  your  organization.  The  questions  are  organized  in  groups  of  key  process  areas  such  as 
software  acquisition  planning  and  acquisition  risk  management.  A  short  paragraph  describing 
each  key  process  area  precedes  each  group  of  questions.  Unless  directed  otherwise  by  the  person 
who  administers  this  questionnaire,  please  answer  the  questions  based  on  your  knowledge  and 
experience  in  your  current  project. 

To  help  us  better  interpret  your  answers  to  the  questions  about  the  software  acquisition  process  in 
your  organization,  this  document  begins  with  questions  about  your  background. 

Please  read  and  answer  all  of  the  questions.  If  you  wish  to  comment  on  any  questions  or  qualify 
your  answers,  please  use  the  comment  spaces  provided. 

Your  answers  will  be  held  in  strict  confidence  by  the  appraisal  team.  Specific  answers  will  not  be 
identified  within  your  organization,  nor  in  any  other  manner.  Your  name  will  be  used  for 
administrative  purposes  only  (i.e.,  to  guide  the  appraisal  team  during  response  analysis  and  help 
them  contact  you  for  any  needed  clarifications). 


Thank  you  for  your  help. 


Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  Pennsylvania  15213-3890 


®  Copyright  1997  Carnegie  Mellon  University 
This  work  is  sponsored  by  the  U.S.  Department  of  Defense. 
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Respondent  Background 

1 .  Please  describe  your  current  position. 

2.  Have  you  received  any  CMM-related  training?  (Please  describe) 


3.  What  is  your  software  acquisition  experience  in:  (Please  specify  for  each  category) 

Your  present  organization? . 

Your  overall  acquisition  experience? . 


YEARS 

YEARS 


4.  Have  you  participated  in  previous  forms  of  Software  Process  Assessments,  Software 
Capability  Evaluations,  and/or  other  forms  of  software  process  appraisals?  (Please  mark  one 
box) 


□  NO 

□  YES 


How  many?  (Please  specify  for  each  category) 

#  OF  SPAs  (Software  Process  Assessments) 

#  OF  SCEs  (Software  Capability  Evaluations) 


#  OF  OTHER  SEI-BASED  METHODS  (Please  describe  briefly: 
e.g.,  mini-assessments  or  instant  profiiesj 


BASED  ON  NON-SEI  PROCESS  IMPROVEMENT  WORK 
(Please  describe  briefly: 
e.g.,  ISO  9000/9001  audit) 
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The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for 
the  software  acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 
Software  Acquisition  Planning  involves  preparation  for  software-related  areas  in  system- 
level  planning  such  as  early  budgetary  action,  schedule  determination,  acquisition 
strategy,  risk  identification,  and  software  requirements  definition. 

acquisition  organization  -  That  entity  which  has  the  oversight  responsibility  for  the  software  acquisition 
project  and  which  may  have  purview  over  the  acquisition  activities  of  a  number  of  projects  or  contract 

actions 

software  acquisition  management  personnel  -  Those  individuals  who  are  trained,  educated,  or 
experienced  in  software  acquisition  management  and  who  are  either  assigned  to  or  support  the  project  team 
in  the  performance  of  software  acquisition  activities 

Does 

Not  Don’t 
Yes  No  Apply  Know 

1.  Are  software  acquisition  planning  personnel  involved  in  system 

acquisition  planning?  .  U  U  U  U 

Comments: 


2.  Does  the  acquisition  organization  have  a  written  policy  or 
guideline  for  planning  software  acquisition? .  ^ 


Comments: 


3.  Does  the  planning  process  provide  for  support  of  the  software 
throughout  its  entire  life  cycle? .  D 


□  □  □ 


□  □ 


Comments: 


4.  Is  a  life-cycle  cost  estimate  for  the  software  activity  prepared  and 
independently  verified  during  the  planning  process? .  □ 


Comments: 


□  □ 
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Yes 


5.  Does  the  acquisition  organization  have  experienced  software 
acquisition  management  personnel? . 

Comments; 


Does 

Not 

No  Apply 


□  □ 


Don’t 

Know 

□ 
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The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of 
a  particular  acquisition  and  to  select  a  contractor  who  is  best  capable  of  satisfying  the 
requirements  of  the  contract.  Solicitation  involves  planning  and  performing  the  activities 
necessary  to  issue  the  solicitation  package,  preparing  for  the  evaluation  of  responses, 
conducting  the  evaluation,  conducting  negotiations,  and  awarding  the  contract. 
Solicitation  ends  when  the  contract  is  awarded. 


periodic  review  -  A  review  that  occurs  at  specified  regular  time  intervals 


policy  -  A  guiding  principle,  typically  established  by  senior  management,  that  is  adopted  by  an  organization 
or  project  to  influence  decisions 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Does  the  acquisition  organization  have  a  written  policy  for  the 
conduct  of  the  software  portion  of  the  solicitation? . 

Comments: 


□  □  □ 


2.  Has  the  responsibility  for  the  software  portion  of  the  solicitation 
been  designated? . 

Comments: 


□  □  □ 


3.  Do  the  people  involved  in  the  solicitation  have  experience  or 
receive  training  in  solicitation  activities? . 

Comments: 


□  □  □ 


4.  Are  the  solicitation  activities  periodically  reviewed  by  the 
designated  selection  official  or  acquisition  organization 
management? . 


□  □  □ 


Comments: 
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The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common 
and  unambiguous  definition  of  software-related  contractual  requirements  that  is 
understood  by  the  project  team,  end  users,  and  the  contractor.  Software-related  contractual 
requirements  consist  of  technical  requirements  (system  requirements  allocated  to 
software)  and  non-technical  requirements  (contractual  agreements,  conditions,  and  terms 
affecting  the  software  portion  of  the  acquisition).  This  key  process  area  is  divided  into  two 
subprocesses:  development  of  software-related  contractual  requirements  and  the 
management  of  these  requirements  for  the  duration  of  the  acquisition. 

baseline  -  A  specification  or  product  that  has  been  foimally  reviewed  and  agreed  upon,  that  thereafter  serves 
as  the  basis  for  future  development,  and  that  can  be  changed  only  through  formal  change  control  procedures 

event-driven  basis  -  A  review  that  is  performed  based  on  the  occurrence  of  an  event  within  the  project  (e.g., 
a  formal  review  or  the  completion  of  a  life-cycle  stage) 

traceability  -  The  ability  to  trace,  in  both  the  forward  and  backward  directions,  the  lineage  of  a  requirement 
from  its  first  level  inception  and  subsequent  refinement  to  its  implementaUon  in  a  software  product  and  the 
documentation  associated  with  the  software  product 


Yes 


Does 
Not  Don’t 
No  Apply  Know 


Are  software-related  contractual  requirements  developed  and 
maintained  in  conjunction  with  the  end  user  and  other  groups  that 

may  be  affected? . 

Comments: 


□  □  □  □ 


Is  there  a  documented  policy  for  establishing  a  software 
requirements  baseline  and  controlling  requirements  changes  to 

that  baseline? . 

Comments: 


□  □  □  □ 


Is  there  a  software-related  contractual  requirements  baseline  and 
is  that  baseline  placed  under  change  control  prior  to  the  release  of 


the  solicitation? . 
Comments: 


□  □  □  □ 
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Does 

Not 

Yes  No  Apply 

4.  Are  changes  to  software-related  contractual  requirements 
evaluated  for  their  impact  on  performance,  architecture, 
supportability,  system  resource  utilization,  and  contract  schedule 
and  cost? .  D  D  D 

Comments: 


5.  Does  a  group  exist  that  performs  requirements  development  and 
management  activities? . 

Comments: 


□ 


6.  Do  the  individuals  who  perform  requirements  development  and 

management  activities  have  experience  or  receive  training? .  D  D  D 

Comments: 


7.  Are  requirements  development  and  management  activities 
reviewed  by  the  project  manager  on  both  a  periodic  and  event- 
driven  basis? .  n  D  n 

Comments: 


Don’t 

Know 


n 


□ 


□ 


□ 


CMU/SEI-97-SR-013 


15 


+ 


The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  contract(s)  to  ensure  a  timely,  efficient,  and  effective  software  acquisition. 
Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling 
project  office  activities  such  as  determining  project  tasks,  estimating  software  size  and 
cost,  scheduling  activities  and  tasks,  training,  leading  the  assigned  personnel,  and 
accepting  software  products  and  services. 


commitment  -  A  pact  that  is  freely  assumed,  visible,  and  expected  to  be  kept  by  all  parties 

software  acquisition  plans  -  The  collection  of  plans,  both  formal  and  informal,  used  to  express  how 
software  acquisition  activities  will  be  performed  (e.g..  Software  Acquisition  Risk  Management  Plan  or 
Project  Management  Plan) 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Do  the  project  management  plans  include  the  activities  to  be 
performed  and  the  commitments  made  for  the  software 
acquisition  project? . . . 

Comments: 


□  □  n 


2.  Are  adequate  resources  provided  for  the  project  team  and  matrix 
support  persons  (e.g.,  funding  and  staff)? . 

Comments: 


□  □  □ 


3.  Does  the  project’s  software  acquisition  management  planning 
documentation  define  the  roles  and  responsibilities  of  the  groups 
involved  in  the  project? 

Comments: 


□  □  □ 


4.  Are  measurements  used  to  determine  the  status  of  the  project 
management  activities  and  resultant  products  (e.g.,  completion  of 

milestones)?  . 

Comments: 


□  □ 
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Yes 


5.  Does  the  project  manager  review  the  project  management 
activities  on  both  a  periodic  and  event-driven  basis? .  □ 

Comments: 


Does 

Not 

No  Apply 

□  □ 


Don’t 

Know 

□ 
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The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  software  activities 
under  contract  are  being  performed  in  accordance  with  contractual  requirements  and  that 
evolving  products  and  services  will  satisfy  contractual  requirements.  Contract  Tracking 
and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the  contractor  s  effort 
and  identifies  risks  and  problems  in  the  effort.  The  contract  provides  the  binding 
agreement  for  establishing  the  requirements  for  the  software  products  and  services  to  be 
acquired.  The  contract  also  allows  the  project  team  to  oversee  the  contractor’s  software 
activities  and  evolving  products  and  to  evaluate  any  software  products  and  services  being 
acquired. 


contract  -  A  binding  agreement  between  two  or  more  parties  that  establishes  the  requirements  for  the 
products  and  services  to  be  acquired 

contract  integrity  -  The  adherence  and  compliance  to  contractual  and  legal  policies,  regulations,  and  other 
guidance 

periodic  review  -  A  review  that  occurs  at  specified  regular  time  intervals 

procedure  -  A  written  description  of  a  course  of  action  to  be  taken  to  perform  a  given  task  [IEEE  90] 


Yes 


1.  Is  there  a  documented  policy  or  procedure  for  tracking  and 

overseeing  the  contracted  software  effort? .  L-* 

Comments: 

/ 

2.  Are  the  contractor  software  planning  documents  approved  and  are 
they  used  to  oversee  the  contractor’ s  software  engineering  effort?  □ 

Comments; 

3.  Does  the  project  team  maintain  the  integrity  of  the  contract  with 
respect  to  changes  to  requirements,  changes  to  terms  and 
conditions,  and  in  coordination  with  all  affected  groups,  including 

the  contractor? .  D 

Comments: 


Does 

Not  Don’t 
No  Apply  Know 


□  □  □ 


□  □  □ 


□  0  □ 
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Yes 

4.  Are  periodic  reviews  and  interchanges  conducted  with  the 
contractor  to  resolve  issues? .  D 

Comments: 


Does 

Not 

No  Apply 

□  □ 


5.  Are  problems  or  issues  found  during  contract  tracking  and 

oversight  recorded  and  tracked  to  closure? .  D  D  D 

Comments: 

6.  Are  measurements  used  to  determine  the  status  of  contract 

tracking  and  oversight  activities  and  resultant  products? .  D  D  D 

Comments: 

7.  Are  the  contract  tracking  and  oversight  activities  reviewed  by  the 

project  manager  on  both  a  periodic  and  event-driven  basis? ..........  D  D  D 

Comments: 


Don’t 

Know 

□ 


□ 


□ 


□ 
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The  purpose  of  Evaluation  is  to  determine  that  the  acquired  software  products  and 
services  satisfy  contract  requirements  prior  to  their  acceptance  and  transition  to  support. 
Evaluations  are  conducted  during  contract  performance  and  results  are  analyzed  to 
determine  acceptability  of  the  software  products  and  services.  Evaluation  begins  with 
development  of  the  system  requirements  and  ends  when  the  software  acquisition  is 
completed. 


defect  -  A  flaw  in  a  system  or  system  component  that  causes  the  system  or  component  to  fail  to  perform  a 
required  function 

evaluation  ■  The  use  of  reviews,  inspections,  and/or  tests  to  determine  that  a  software  product  or  service 
satisfies  its  specified  requirements 


Does 

Not  Don’t 
Yes  No  Apply  Know 

1 .  Does  the  acquisition  organization  have  a  written  policy  to  manage 

evaluation?  .  D  D  D  D 

Comments: 

2.  Are  all  products  and  services  evaluated  before  acceptance?  .  D  D  D  D 

Comments: 

3.  Is  a  group  established  that  is  responsible  for  planning,  managing, 

and  performing  evaluation  activities? .  [D  D  D  D 

Comments: 

4.  Are  measurements  used  to  determine  the  status  of  the  evaluation 

activities  and  resultant  products? .  D  D  D  D 

Comments: 
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Yes 

5.  Are  the  evaluation  activities  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis?  .  >— I 

Comments: 


Not 

No  Apply 

□  □ 


Don’t 

Know 

□ 
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The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  software 
products  being  acquired  to  the  software  support  organization.  The  necessary  resources  are 
identified,  budgeted  for,  and  available  when  needed.  The  designated  software  support 
organization  is  fully  prepared  to  accept  responsibility  for  the  software  products  in  time  to 
ensure  uninterrupted  support.  Transition  to  Support  involves  developing  and 
implementing  plans  for  transitioning  the  acquired  software  products.  It  also  involves 
ensuring  that  the  contractor  and  the  software  support  organization  are  informed  on  the 
contents  of  the  software  engineering  and  support  environments. 


software  support  -  The  process  of  modifying  a  software  system  or  component  after  delivery  to  correct 
faults,  improve  performance  or  other  attributes,  or  adapt  to  a  changed  environment  [IEEE  90] 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Is  there  a  documented  policy  or  procedure  for  the  transition  of 

software  products  to  the  software  support  organization? .  D  D  D  D 

Comments: 

2.  Are  the  resources  for  software  support  included  in  the  appropriate 

budget? .  □  □  □  □ 

Comments: 

3.  Has  responsibility  for  the  transition  of  software  to  the  software 

support  organization  been  designated? .  D  □  □  □ 

Comments: 


4.  Does  the  project  team  oversee  the  configuration  control  of  the 

software  products  during  the  transition  phase? .  □  □  □  D 

Comments: 
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Does 

Not  Don’t 
Yes  No  Apply  Know 

5.  Are  the  transition  to  support  activities  reviewed  by  the  project 

manager  on  both  a  periodic  and  event-driven  basis? .  D  D  D  D 

Comments: 

6.  Are  the  transition  to  support  activities  reviewed  by  the  acquisition 
and  software  support  organization’s  management  on  a  periodic 

basis? .  n  D  D  n 

Comments: 
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The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisidon 
organization's  standard  software  acquisition  process  and  an  organizational  responsibility 
for  stabilizing  and  maintaining  the  standard  software  acquisition  process.  Process 
Definition  and  Maintenance  involves  understanding  the  organization's  and  projects' 
software  acquisition  processes,  collecting  a  set  of  software  acquisition  process  assets,  and 
coordinating  efforts  to  appraise  and  improve  software  acquisition  processes.  The 
acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish 
and  maintain  a  software  acquisition  process  group.  This  group  is  responsible  for  the 
definition,  maintenance,  and  improvement  of  the  acquisition  organization  s  standard 
software  acquisition  process  and  other  process  assets,  including  guidelines  for  projects  to 
tailor  the  standard  software  acquisition  process  to  their  specific  situations. 


project  team  -  All  individuals  that  have  an  assigned  software  acquisition  responsibility  in  the  contracted 
effort.  A  project  team  may  vary  in  size  from  a  single  individual  assigned  part  time  to  a  large  organization 
assigned  full  time 

software  acquisition  process  -  A  set  of  activities,  methods,  practices,  and  transformations  that  people  use  to 
acquire  software  and  the  associated  products 

software  acquisition  process  repository  -  A  collection  of  software  acquisition  process  information  (e.g., 
estimated  and  actual  data  on  software  project  size,  effort,  and  cost;  and  project  team  productivity  and  quality 
data)  gathered  from  the  software  acquisition  projects  that  is  maintained  by  the  acquisition  organization  to 
support  its  software  acquisition  definition,  maintenance,  and  improvement  activities 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Is  a  standard  software  acquisition  process  for  your  acquisition 
organization  defined  and  maintained? . 

Comments: 


□  □  □ 


2.  Are  the  activities  for  defining  and  maintaining  the  software 
acquisition  processes  coordinated  across  the  acquisition 
organization? . 

Comments: 


□  □  □ 
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Does 

Not  Don’t 
Yes  No  Apply  Know 

3.  Does  your  acquisition  organization  collect,  analyze,  and  make 
available  information  related  to  the  use  of  the  organization’s 

standard  software  acquisition  process? .  □  □  □  □ 

Comments: 

4.  Does  your  acquisition  organization  have  a  group  that  is 
responsible  for  the  acquisition  organization’s  definition  and 
maintenance  process  activities  (e.g.  a  software  acquisition  process 

group)? .  D  n  D  D 

Comments: 


5.  Do  the  individuals  that  are  responsible  for  the  acquisition 
organization’s  software  acquisition  process  activities  have 
experience  or  receive  required  training  in  process  definition  and 

maintenance  activities? .  □  □  □  D 

Comments: 


6.  Are  measurements  used  to  determine  the  status  of  the  process 
definition  and  maintenance  activities  and  resultant  products  (e.g., 

completion  of  milestones,  effort  expended,  and  funds  expended)?  D  D  D  D 
Comments: 


7.  Are  the  activities  performed  to  define  and  maintain  the 
acquisition  organization’s  software  acquisition  process  reviewed 

periodically  with  acquisition  organization  management? .  D  D  D  D 

Comments: 
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The  purpose  of  Project  Performance  Management  is  to  manage  the  software  acquisition 
project  according  to  a  defined  software  acquisition  process.  Project  Performance 
Management  involves  developing  the  project’s  defined  software  acquisition  process  and 
managing  the  acquisition  using  this  defined  process.  The  project  s  defined  software 
acquisition  process  is  tailored  from  the  acquisition  organization’s  standard  software 
acquisition  process  to  address  specific  attributes  of  the  project.  The  project’s  management 
plans  describe  how  the  project’s  defined  acquisition  process  will  be  implemented  and 

managed. 

project’s  defined  software  acquisition  process  -  The  project’s  tailored  version  of  the  acquisition 
organization’s  standard  software  acquisition  process 

tailor  -  To  modify  a  process,  standard,  or  procedure  to  better  match  process  or  product  requirements 


Yes 


Does 
Not  Don’t 
No  Apply  Know 


1.  Was  the  project’s  defined  software  acquisition  process  developed 
and  documented  by  tailoring  the  acquisition  organization’s 
standard  software  acquisition  process? .  LJ 

Comments: 


□  □  □ 


2.  Are  the  project’s  software  acquisition  activities  planned  and 
performed  in  accordance  with  the  project’s  defined  software 
acquisition  process? . 

Comments: 


□  □  □ 


3.  Are  measurements  used  to  determine  the  status  of  the  project 
performance  management  activities  and  resultant  products?  . 

Comments: 


□  □  □ 


4.  Are  the  project  performance  management  activities  periodically 
reviewed  by  acquisition  organization  management?  . 

Comments: 


□  □ 


□ 
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The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  software  products  and  services 
that  satisfy  contract  requirements.  Additional  activities  include  contributing  to  the 
project’s  risk  management  activities,  fostering  an  environment  of  mutual  cooperation  with 
the  contractor,  and  identifying  improvements  to  the  contract  performance  management 
process. 


contract  -  A  binding  agreement  between  two  or  more  parties  that  establishes  the  requirements  for  the 
products  and  services  to  be  acquired 

tailor  -  To  modify  a  process,  standard,  or  procedure  to  better  match  process  or  product  requirements 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Is  there  a  written  policy  for  contract  performance  management 

activities?  . 

Comments: 


□  ,  □  □ 


2.  Is  there  a  documented  plan  for  contract  performance  management 

activities? . 

Comments: 


□  □  □ 


3.  Are  the  contractor’s  software  engineering  processes  and  the 
resulting  products  and  services  evaluated  to  determine  if  they 
satisfy  contractual  requirements? . 

Comments: 


□  □  □ 


4.  Do  the  contract  performance  management  activities  foster  a 
cooperative  environment  between  the  project  team  and  the 

contractor? . 

Comments: 


□  DO 
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Does 

Not  Don’t 
Yes  No  Apply  Know 

5.  Are  measurements  used  to  determine  the  status  of  the  contract 

performance  management  activities  and  resultant  products?  D  D  D  D 

Comments: 


6.  Are  the  contract  performance  management  activities  reviewed  by 
acquisition  organization  management  on  a  periodic  basis? .  0 

Comments: 


□ 
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The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible, 
adjust  the  acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk 
management  process  as  an  integral  part  of  the  acquisition  organization’s  standard 
software  acquisition  process.  Acquisition  risk  management  is  a  two-part  process.  First,  the 
software  acquisition  strategy  identifies  the  risks  associated  with  the  acquisition  of  the 
system  and  the  approach  is  planned  based  on  those  risks.  Second,  a  process  is  employed  to 
manage  the  risks  throughout  the  acquisition. 


risk  management  -  The  process  associated  with  identifying,  evaluating,  mitigating,  and  controlling  project 
risks 


Does 

Not  Don’t 
Yes  No  Apply  Know 


1.  Does  the  acquisition  organization  have  a  written  policy  for 
acquisition  risk  management? . 

Comments; 


□  □  □ 


2.  Has  responsibility  for  acquisition  risk  management  activities  been 
designated? . 

Comments: 


□  □  □ 


3.  Are  software  acquisition  risk  management  activities  integrated 
into  software  acquisition  planning?  . 

Comments: 


□  □  □ 


4.  Is  the  Software  Acquisition  Risk  Management  Plan  developed 

according  to  the  project’s  defined  software  acquisition  process? ...  □  □  □ 

Comments: 
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Yes 


5.  Are  risk  management  activities  conducted  during  contract 
performance  management? . 

Comments: 


Does 

Not 

No  Apply 

□  □ 


6.  Are  risk  mitigation  actions  tracked  to  completion? 
Comments: 


□  □  □ 


Don’t 

Know 

□ 


□ 
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The  purpose  of  Training  Program  is  to  develop  the  skills  and  knowledge  of  individuals 
so  they  can  perform  their  software  acquisition  roles  effectively  and  efficiently.  Training 
Program  involves  the  appraisal  of  training  requirements  at  the  acquisition  organization, 
project,  and  individual  levels.  Some  skills  are  effectively  and  efficiently  imparted  through 
informal  vehicles,  whereas  other  skills  need  more  formal  training  vehicles  to  be 
effectively  and  efficiently  imparted.  The  appropriate  vehicles  are  selected  and  used. 


training  program  -  The  set  of  related  elements  that  focuses  on  addressing  an  organization’s  training  needs. 
It  includes  an  organization’s  training  plan,  training  materials,  development  of  training,  conduct  of  training, 
training  facilities,  evaluation  of  training,  and  maintenance  of  training  records 


1 .  Are  training  program  activities  planned? 
Comments: 


Does 

Not  Don’t 
Yes  No  Apply  Know 

□  □  □  □ 


2.  Does  each  software  acquisition  project  identify  specific  training 
needs  and  develop  a  training  plan  in  accordance  with  training 
program  procedures? . 

Comments: 


□  □  □ 


3.  Are  adequate  resources  provided  to  implement  the  organization’s 
training  program  (e.g.,  funding,  staff,  equipment,  tools,  and 
appropriate  facilities)?  . 

Comments: 


□  □  □ 


4.  Are  measurements  used  to  determine  the  status  of  the  training 
program  activities  and  resultant  products? . 

Comments: 


□  □ 


□ 
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5.  Are  training  program  activities  reviewed  by  organization 
management  on  a  periodic  basis? . 

Comments; 


□  □  □ 
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Organizational  Terms 


The  following  definitions  include  all  of  the  organizational  terms  used  in  the  Software  Acquisition 
Capability  Maturity  Model  to  provide  a  context  relating  to  the  organizational  terms  used  in  the 
Maturity  Questionnaire. 

acquisition  organization  -  That  entity  which  has  the  oversight  responsibility  for  the  software 
acquisition  project  and  which  may  have  purview  over  the  acquisition  activities  of  a  number  of 
projects  or  contact  actions 

affected  groups  -  Groups  with  related  responsibilities  or  obligations  whose  work  performance 
might  be  impacted.  Such  groups  might  include  end  users,  evaluators,  software  engineering, 
management  staff,  and  contractors 

contractor  -  The  entity  delivering  the  product  or  performing  the  service  being  acquired,  even  if 
that  entity  is  part  of  the  acquiring  organization 

end  user  -  The  individual  or  group  who  will  use  the  system  for  its  intended  operational  use  when 
it  is  deployed  in  its  environment 

manager  -  A  role  that  encompasses  providing  technical  and  administrative  direction  and  control 
to  individuals  performing  tasks  or  activities  within  the  manager’s  area  of  responsibility.  The 
traditional  functions  of  a  manager  include  planning,  resourcing,  organizing,  directing,  and 
controlling  work  within  an  area  of  responsibility 

offeror  -  A  contractor  who  submits  a  proposal  in  response  to  a  solicitation  package 
organization  -  The  parent  organization  of  the  acquisition  organization 

project  -  An  undertaking  that  is  focused  on  acquiring  a  specific  product.  The  product  may  include 
hardware,  software,  and  services.  Typically,  a  project  has  its  own  funding,  cost  accounting,  and 
delivery  schedule 

prime  contractor  -  An  individual,  partnership,  corporation,  or  association  that  administers  a 
subcontract  to  design,  develop,  and/or  manufacture  one  or  more  products 

project  manager  -  The  role  with  total  business  responsibility  for  an  entire  project;  the  individual 
who  directs,  controls,  administers,  and  regulates  a  project  acquiring  software,  a  hardware/ 
software  system,  or  services.  The  project  manager  is  the  individual  ultimately  responsible  to  the 
end  user 

project  office  -  The  aggregate  of  individuals  assigned  the  primary  responsibility  for  software 
acquisition  in  the  contracted  effort.  A  project  office  may  vary  in  size  from  a  single  individual 
assigned  part  time  to  a  large  organization  assigned  full  time 
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project  team  -  All  individuals  that  have  an  assigned  software  acquisition  responsibility  in  the 
contracted  effort.  A  project  team  may  vary  in  size  from  a  single  individual  assigned  part  time  to  a 
large  organization  assigned  full  time 

software  acquisition  management  personnel  -  Those  individuals  who  are  trained,  educated,  or 
experienced  in  software  acquisition  management  and  who  are  either  assigned  to  or  support  the 
project  team  in  the  performance  of  software  acquisition  activities 

software  acquisition-related  group  -  A  collection  of  individuals  (both  managers  and  technical 
staff)  representing  a  software  discipline  that  supports,  but  is  not  directly  responsible  for,  software 
acquisition.  Examples  of  software  disciplines  include  software  configuration  management  and 
software  quality  assurance 

software  engineering  group  -  The  collection  of  individuals  (both  managers  and  technical  staff) 
who  are  responsible  for  software  development  and  maintenance  activities  (i.e.,  requirements 
analysis,  design,  code,  and  test)  for  a  project.  Groups  performing  software-related  work,  such  as 
the  software  quality  assurance  group  and  the  software  configuration  management  group,  are  not 
included  in  the  software  engineering  group 

software  engineering  personnel  -  Those  individuals  who  are  trained,  educated,  or  experienced  in 
software  engineering  and  who  are  either  assigned  to  or  support  the  project  team  in  the 
performance  of  software  acquisition  activities 

subcontractor  -  An  individual,  partnership,  corporation,  or  association  that  contracts  with  an 
organization  (i.e.,  the  prime  contractor)  to  design,  develop,  and/or  manufacture  one  or  more 
products 
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Change  Request  Form 


Feel  free  to  write  in  any  available  space,  or  attach  extra 
sheets,  if  you  have  additional  concerns,  wish  to  make 
suggestions  for  improvement,  comment  further  on  any 
questions,  or  qualify  your  answers. 


Date: 


Product  Reviewed: 


Version  Reviewed: 


Name  of  Submitting  Organization: 


Reviewer’s  Name: 


Reviewer’s  Telephone: 


Reviewer’s  Titie: 


Reviewer’s  E-Mail  Address: 


Reviewer’s  Mailing  Address: 


Short  Descriptive  Title  for  Change: 


Location  of  Change: 


Page  Number: 


Paragraph  Number: 


Key  Process  Area: 


Common  Feature: 


Other  Identifiers: 


Proposed  Change: 


Rationaie  for  Change 


fT 


*»ShadeUareas  tb  be  filled  m  by 


Mir 


Note:  For  the  SEI  to  take  appropriate  action  on  a  change  request,  we  must  have  a  clear  description  of  the  recommended  change, 
along  with  a  supporting  rationale. 

SendUS  mail  to:  Change  Requests,  Risk  Program  and  Acquisition  Risk  Management  Initiative,  Software  Engineering  Institute, 
Carnegie  Mellon  University,  Pittsburgh,  PA  15213-3890 

Send  packages  to:  Change  Requests,  Risk  Program  and  Acquisition  Risk  Management  Initiative,  Software  Engineering  Institute, 
Carnegie  Mellon  University,  4500  Fifth  Avenue,  Pittsburgh,  PA  15213-2691 

Send  via  Internet  to:  SA-change@sei,cmu.edu 
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